The management of complex services associated with enterprise messaging can be difficult. For example, there are multiple users/administrators that need to have different levels of access. Assigning these permissions with sufficient granularity over a multitude of heterogeneous resources (e.g., files, email items, objects in directory, etc.) is a challenging task because the assignment depends on the what user needs to perform the associated business function, as well as implementation details of what these business functions need to touch in order to perform desired action. These implementation details can change over time. For example, creating a new mailbox requires permissions to create a new user account, modify several properties, and access to a particular mailbox database. Additionally, the auditing of resources-level permissions is difficult because the permissions are spread all over directory, file system, mailboxes, etc. Even if there was a way to accurately obtain all ACLs (access control lists) relevant to a particular user, it would still be challenging to explain why a particular permission is needed (e.g., which business function requires the permission). Moreover, with multiple administrators touching permissions it is easy to misconfigure ACLs. A relatively recent technology, a role-based access control (RBAC) model, employs fixed sets of roles that relate to job functions. RBAC works by assigning fixed permissions to all resources needed by a user to perform actions related to the role. However, it is common for subsequent (i.e., upgraded) versions of a product that uses RBAC to change the meanings of existing roles. Thus, a role in upgraded version X+1 of an RBAC product may contain more or fewer permissions than in an existing version X, and thus not be the same between versions. For example, in version X+1, it may be desirable to remove certain permissions from an existing role because they no longer fit the new definition of the role (or there was a problem with the original role definition). Even more common may be the scenario where new actions need to be added to the existing roles. Furthermore, management roles may need to be deprecated (i.e., deleted) once they are no longer useful or simply split into several additional roles when the meaning of a single management role defined in version X is too broad. Moreover, due to the nature of parameterized actions (such as cmdlets) some parameters may get renamed, removed, added, or simply just moved from one management role to another. As a result, users of an RBAC product may be affected by the aforementioned changes when the upgraded version is deployed. It is with respect to these considerations and others that the various embodiments of the present invention have been made.